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He runs Korean security mailing list called Bugtruck(not bugtraq). 

Introduction 

The Problem 

Security patches are usually meant to fix security vulnerabilities. And thost are for fixing problems and 
protect computers and end users from risks. But how about releasing patch imposes new threats? We 
call the threat "1-day exploits". Just few minutes after the release of patches, binary diffing technique 
can be used to identify the vulnerabilities that the security patches are remedying. It's ironical situation 
but that's what is happening these days. 

This binary diffing technique is especially useful for Microsoft's binaries. Not like other vendors they 
are releasing patch regularly and the patched vulnerabilities are relatively concentrated in small areas in 
the binary. Those facts make the patched area in the binary more visible and apparent to the patch 
analyzers. 

We already developed "eEye Binary Diffing Suites" back in 2006 and it's widely used by security 
researchers to identify vulnerabilities. It's free and open-source and it's powerful enough to be used for 
1-day vulnerabilities hunting purpose. So virtually, attackers have access to all the tools and targets 
they need to identify unknown vulnerabilities that is just patched. They can launch attack during the 
time frame users or corporates are applying patches. This process typically takes few minutes to few 
days. 

From our observations during past few years, all the important security patches were binary diffed 
manually or automatically using tools. Sometimes the researchers claimed they finished analyzing 
patches in just 20-30 minutes. At most in a day, it's possible to identify the vulnerability itself and make 
working exploits. And binary diffing has now become too easy and cheap to the attackers. During patch 
applying time frame, the end users are more vulnerable and targeted using 1-day attack. 

The Answer 

So now it became crucial to make theses 1-day exploits more difficult and time-consuming so that the 
vendors can earn more time for the consumers to apply patches. Even though using severe code 
obfuscation is not an option for Microsoft's products, they can still follow some strategies and 
techniques to defeat the binary diffing processes without forsaking stability and usability. We are going 
to show the methods and tactics to make binary differs life harder. And will show the in-house tool that 
obfuscates the binaries in a way that especially binary differs confused. We call this process anti-binary 
diffing. 



Binary Diffing 
The History 

Since being introduced 10 years ago by Bmat paper [BMAT], binary diffing is now so common and 
easily affordable technique. Aside from expensive commercial tools like "bindiff ', there are already 2-3 
free or opensource tools that can be used to identify exact patched points in the patch files. 
Here we are presenting the brief history of binary diffing theories and tools. 

BMAT(1999) 

It severely depends on symbolic name matching. It was mainly used for Microsoft's binaries which 
symbol they have access to. With name-based matching, after matching procedure or function is 
identified, it conducts hashing-based comparison for the blocks inside each procedure. It's using 64bit 
hash value calculated from the instructions and the checksum is order dependent. Hashing is generated 
from instruction bytes. There are multiple level of abstractions with opcode and operands. 
This paper is mainly focused on transfer of profile propagation and not in security patch analysis. The 
strength of this paper is that it suggested using checksum for block matches. Sometimes same block 
can be changed without code change by code optimizations. But usually the vendors doesn't change the 
optimization level and the registers and order of instructions in basic blocks usually remains same. So 
just doing checksumming basic blocks and compare them instead of whole instruction text will be 
acceptable in normal times. Also they showed 5 different levels of checksumming method for the basic 
blocks. They call these levels "matching fuzziness levels". As the level decreasess more and more 
information the hash has will use for calculation. The level basically has all the information of the 
basic block including register allocation and block address operand and operands and opcodes. Level 5 
has only opcode information. 

This paper also presented CFG based basic block matches. So this match method is actually the basic 
method for binary diffing. 

Automated Reverse Engineering(2004) 

Halvar presented at Blackhat 2004 on reverse engineering techniques [ARE]. And he suggested using 
fingerprints of functions for binary diffing. Basically same idea is used for his following papers and 
bindiff tool. The idea is unique and simple. Using number of nodes and edges and number of calls as 
traits, construct a function signature. And compare them between binaries. It suggests isomorphic 
comparison between functions CG(call graph)s. 

Comparing binaries with graph isomorphism(2004) 

Todd Sabin suggested isomorphic analysis and matching two binaries [TODD]. It's based on 
instructions graph's isomorphic matching. It adopted divide and conquer strategy to diff whole 
structure. The interesting point is that it compares instructions not basic blocks. But the instruction 
comparison is merged as basic block matching and function matching. He claimed the binary diffing 
performance is acceptable and usable. But no POC ever released. 



Structural Comparison of Executable Objects(2004) 

Improved version of Halvar's Blackhat 2004 "Automated Reverse Engineering(2004)"[ARE] 
presentation[SCEO] . 



Graph-based comparison of Executable Objects(2005) 

Halvar improved previous paper "Structural Comparison of Executable Objects(2004)". The basic idea 
is same. 

The problem is that the algorithm is heavily dependent on CFG generation from the binaries. As the 
paper is saying in modern day binaries it's not simple work to extract CFG and CG. The complete CFG 
analysis of binary itself is a challenging work and any inconsistency in CFG can result in major 
analysis failure of whole binaries. 

You can ignore CFG recognition failure, but it means a lot of false negatives. And there are some 
chances you miss important parts. Also this algorithm can't catch patches not incurring any structural 
changes like by using constant values or register changes. 

The Tools 

We are going to present all the major binary diffing tools out until now(commercial or freeware). We 
also compare their algorithms and show how effective in real world. 

Sabre Security's bindiff(2004) 

Halvar made a commercial binary diffing tool based on his graph based fingerprinting theory. 



IDACompare(2005) 

Based on the description of the tool, it looks like it's based on signature scanning. We didn't test the tool 
but it's mainly targeted for porting malware analysis data porting. It's also using mdb and the page says 
it's designed for around 500k file in size. For normal patch diffing the binary file can be more than 1M 
Bytes to 10 to 20 Mbytes. 

eEye Binary Diffing Suite(2006) 

We at eEeye, developed a opensource binary diffing suite back in 2006 summer. It was used internally 
for Microsoft's Patch Tuesday patches analysis. At that times, Microsoft didn't provide patch 
information to the vendors and patch analysis was the only way to obtain some secret information they 
don't release. 

The "DarunGrim" is one of the tools included and performs the main binary diffing analysis. The tool 
used sqlite database to save differential analysis results. The main algorithm used in this tool is 
basically used in DarunGrim2, also. Because it was written in Python, it had low performance when 
the analysis target is bigger than around 10 mega bytes. And this is solved by using C++ instead of 
Python in DarunGrim2. 

Patchdiff2(2008) 

From the description of the tool, this tool is made specifically for security patch or hotfix analysis. This 
is not suitable tool for similar functions finding or malware similarities research. This is a freely 
distributed tool from Tenable Security. From the document, looks like they are using checksum of 
graph call for signaturing, which mean they have similar scheme as Halvar's. 



DarunGrim2 

This is the improved version of eEye Binary Diffing Suite. The major difference is that it's using C++ 
instead of Python. Aside from that it introduced a lot of improvements over the past version of 
DarunGrim. 

DarunGrim2 
Algorithms 

We are going to present all known binary diffing algorithms, tactics that can be practically used. We 
will explain the algorithms that are used by diffing tools one by one with experimental data we 
collected. Some statistical method will be used to show the effectiveness of each algorithms. Mere 
simple looking algorithms can be surprisingly powerful in identifying serious vulnerabilities. 
The engine is based on fingerprint hashing method to match procedures fast and in reliable way. The 
previous works in binary difference analysis were mainly concentrated on the graph structure analysis 
and graph isomorphism. But they involve intensive comparison of two graphs and also has a drawback 
like depending on the disassembler's CFG analysis capabilities. If the CFG is not complete whole 
procedure will remain unmatched. Some pattern like indirect call can't be analyzed using isomorphic 
analysis. Name matching is also widely used for procedure matching but if the symbol is not available, 
this is not an option. 

Fingerprint hashing is the way to overcome this limitation and to improve analysis result drastically. It 
also has benefit of high performance. We are presenting the way to implement the fingerprint hashing 
and will show some real binary differences analysis examples. 

But fingerprint hashing is not the only algorithms used in DarunGrim2, there are also some algorithms 
to match functions based on fingerprint matching. DarunGrim2 is also using traditional isomorphic 
algorithms and name matching. 

Symbolic Names Matching 

DarunGrim2 is using symbolic name matching as like other binary diffing tools. It's a basic starting 
points for binary matching procedure. The symbolic name can be exported name or names retrieved 
from vendor provided symbol . Usually the symbol file is not provided to the public, but Microsoft is 
kind enough to provide symbol files to anyone as soon as the patch is out. So it helps a lot with binary 
diffing process and actual tracing of the vulnerabilities. 

Fingerprint Hash Map 

What is a fingerprint? 

We are presenting fingerprint hashing method as main algorithm of DarunGrim2. This method is very 
simple. Also it can be implemented without any intensive analysis of binaries. Fingerprint hashing is 
using a way to abstract the instruction sequences. 

In general, fingerprint can have multiple meanings in computer science. In this article fingerprint is 
used to express a data bytes representing a basic block. For every basic blocks DarunGrim2 extract 
code bytes features and use that as a key to hash table. We call that fingerprint of the block. The size 
can be variable and relative to sum of the actual instructions bytes size. There can be many ways to 
make fingerprint. 



Fingerprint matching is a method for matching basic blocks efficiently. Basic block is the basic element 
for differential analysis. It's a basic block that has one or more code referencing blocks. Building hash 
table takes O(n). DarunGrim2 build two fingerprint hash table for original binary and patched binary. 
For each unique fingerprints from original binary fingerprints, DarunGrim2 check if the patched 
binaries fingerprint hash table has matching entry. This procedure takes O(n) because searching hash 
table takes 0(1). 

Unlike flirt-like traditional function level fingerprint DarunGrim2 is using abstracted forms of 
fingerprint bytes as a hash data for basic blocks. So even though some of the basic blocks in a function 
is modified, other matching basic blocks support the function matching. For faster matching of 
enormous number of fingerprint hashes generated, we put all unique fingerprint strings to hash table 
and use them for matching fingerprints. There can be many ways to generate the fingerprint for a basic 
block. And as you switch the fingerprint generation method, it shows different behavior in the matching 
process. 



Generating fingerprint for a basic block 

The simplest way to generate fingerprint of a basic block is using opcodes and operand. Because 
fingerprint generation of the basic blocks are most crucial part in this method, there are few things to 
consider in generating fingerprints depending on the compiler and link options. We can determine to 
ignore memory or immediate type operands, because they tend to change with source code 
modification. We might choose to ignore any register differences and make them as one representation. 
There can be multiple way of fingerprint generation methods. 



Using IDA 

The implementation is using IDA for binary analysis. So the fingerprint generation is dependent on 
IDA's disassembly representation. And IDA is providing good structure to extract this information. 
DarunGrim2 plugin is using insnt structure to retrieve information on instructions. 



Overcoming Order Dependency 

The drawback of simple sequential extraction of fingerprint is that it's order dependent. Actually this 
problem is common for any algorithms dependent on instructions order. So to solve this problem we 
also have option to perform instruction ordering normalization before generating any signatures. This is 
done by choosing instructions that is dependent each other. And sort them by instruction bytes 
ascending order. Any dependent instructions sequence should maintain their order anyway. This 
instruction ordering normalization is especially important for the binaries built with compilers doing 
aggressive optimization using instruction reordering. 



Reducing Hash Collision 

There can be short basic blocks and they tend to have duplicates in one binary. That is to say, there can 
be fingerprints that is not unique in the binary. This makes hash collision when used in hash table. 
Basically we ignore and don't use the entries that has conflicts for comparison. But there are better way 
to make the collision rate low. By associating one blocks fingerprint with next connected blocks in 
fingerprint CFG, we have some chances of making the collision blocks unique. In that way we can use 
fingerprint hashing for multiple linked blocks and reduce the number of collisions. 



Determining functions matching pair 

After hash table traverse and matching blocks, we go through every procedures in original binary to 
calculate the number of matches to the procedures in patched binary. If one procedure has basic blocks 
matching to different procedures in patched binary, we need to select one of them. We use simple 
method to accomplish this. We just count the number of matching entries for each matching couples 
and we select the match with highest number. If there are multiple entries with same highest number, 
we need to select one of them randomly. 

So, the matching functions are determined by comparing the matching counts for each functions and 
selecting the function match pair that has biggest matching count. If the matching function is 
determined, any non-compliant matching pairs which has matching basic block in non-matching 
functions will be revoked. 

So the determining process for matching functions is mainly dependent on fingerprint matching. And 
for the real world patches, we found that fingerprinting basic blocks showed good performance and 
quality. 



Matching blocks inside function 

If matching functions are determined, the blocks inside each functions will have some kind of a 
locality. So we again construct fingerprint hash table for basic blocks inside each function and can 
perform fingerprint match on that. This is called "fingerprint match inside function". In this case the 
node number is relatively small. The collision probability is also very low compared to the global 
fingerprint match performed before. 



How does it look like? 

Here's the example of fingerprint representation inside database. 



id FilelD StartAddress EndAddress Flag FunctionAddres BlockType Name DisasmLinss 


Fingerprint 






1535545159 1535545160 139 


1535545164 




























:c8f0102cc5c01020302ccd101020102cc0601{ 














881 j*[ 




\T^W ^5^ M 


IsImsto 


push ecx 


:cBf0102cc8f0402cc8f0102cc120202cc[>6{}102 


m~\ m 




- '.] 1535545248 139 


1535545164 


loc_5BS6SF9E pop esi 


: c860102r,a60102-9f0501 


884 884 




1535545251 1535545259 144 




loc_5B86SFA3 mov eax, [ebp 


:c7a01020402cc07D3020502ccd801020102 


















•E3554E264 -=3=54=268 139 


1E3EE4E27" 


0word_5BS6BFB0dwQ 
























PU* [ebp+uBi 




























891 891 




















lea B ax.(_lm: 




893 395 




153EE4E374 iE3EE4E379 255 


■E3EE4E3C3 


loc_5BS6901E test edx. edx 


:cd201020ia2cc7a04020102 














895 S9E 




"E3EE4E3S3 "5555154C8 83 


■S33E4E3C3 


loc_5B869037 mov era. [ebp 


-h . . i 11 .cc860102cc7a{)30201 


























898 £93 












899 899 




■.535545483 "333343492 139 




loc 53369090 cmo [ebp+ara 


:clb04020502 



Illustration 1: Query Results from Sqlite database showing Fingerprint entries. 



Structure Based Analysis 

Structure based analysis: basic block isomorphism 

After determining matching functions and finishing fingerprinting match inside function, we perform 
structure based analysis. But, it's definitely not Halvar's method. Our method is just procedural and has 
a philosophy of divide and conquer. Because we are using basic blocks as graph node, it's different 
from Todd's isomorphic algorithm. As far as I know, this matching algorithm is similar to that is 
presented in BMAT tool [BMAT]. From the known matched nodes, it will try to match their children's 
nodes. 

Control flow Inversion 

In this process, we need to consider control flow inversion. Control flow inversion issue is already 
known from Todd's document [TODD]. DarunGrim2 just tweaks the CFG when we encounter any 
negative comparison type jumps(jnz,jle, etc). 

Here's some C style pseudo code showing the code inversion removal process. 




Calculating Match Rate 

When performing procedural structural matching, we need to determine if two basic blocks are same or 
similar. We use fingerprint as a means for performing this operation. Because fingerprint is extracted 
from real code instructions, it shows the real implementation of the basic block and also has been 
abstracted and normalized for analysis. The fingerprint is stored as binary byte sequences in the 
memory when the fingerprint matching is performed, but it can be easily converted to hex ascii form 
representation. With converted form of ascii string we use well known string matching algorithms to 
calculate similarities of the basic blocks. This part is a little bit time-consuming and will have more 
false match rate if we used real instruction bytes or disassembly representation of the basic block. 

So after all this process is finished we will repeat whole matching process again with unmatched code 



blocks that is not a member of any matching procedures. We repeat this process until there is no 
matching entries produced by any methods. 

In real world examples, especially circumstances like Microsoft patch analysis, fingerprint matching 
and procedural structural matching is enough for identifying the patched part of the binary. 



Real Life Issues 

There are some issues with diffing real binaries because eash vendors are using different compilers and 
optimization methods. We are going to show some issues we encountered during binary diffing actual 
binaries. 



Split Blocks 

As a part of optimization, there are some blocks that is split in multiple location. We can define split 
block as like following. 

"The block who has one child and the child of the block has only one parent in CFG." 

The split blocks tend to make CFG broken and the matching process incomplete. Here's a example of 
the situation. 757AC02B block in left pane and 7CB411B5+7CB411BA blocks in right pane is same. 
But the blocks in right pane is split and all the children blocks is colored in red which means they are 
not recognized as matching blocks, even though they are matching. 



File Graphs Help 


nii.iim.iiM 




lag 


\^^% 


sub_757ABEF5 


sub_7CB4CF9C 




■* It 


- 




^ t r 


SSI- 




757AC02B 


7CB41185 


or [ebp+var 4] , OFFFFFFFFh 
call sub 757AC11B 

'"07 £3X. .£33-VS"_i-. 

"::■■.■ esai. "S33-5-C - 

cmp dword ptr [eax+0Ch\ 2 

•■: :: "S'^C:* 


or [ebp+var 4] , OFFFFFFFFh 
call sub" 7C5-::?5 

'"::■■.■ £DX. "S33 --.•*•■ 2- 

'■::■■:•. ':: "IE -LIE- 




































II 


< 




■ 


< 




> 










List Of Matches 










Functions Blocks ] 


Original Patched | Match ... | Type 


F'nasrp ni'' _i'n? F'n:_isrptTi:::'~a:d"ied "aremfOriqi... Pare *> 


□ 757AC162 

□ 757ACQ4E 

□ 757ABFA5 7CB4103B 100% Finge 

□ 757ABF9E 7CB41031 100% Tree 


7a010204027a0102... 

2C0402 
r... 0S010205028f0402... 06010205028f0402... 

8f0502 8f0502 757ABFSC 



7CB v 








u 



Illustration 2: Split Blocks(L: 757AC02B=R: 7CB41185+R: 7CB411BA) 



DarunGrim2 recognizes these split blocks and merges them in one block. After applying this merging 
process, here's the result of binary matching for same code blocks. 
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Illustration 3: Now the blocks are merged in right(7CB41185) 



You can see that all the unmatched blocks are now matched. 



Hot Patching 

Microsoft's binaries sometimes has hot patch instructions just before the real function starts. Here's an 
example of a function with hot patch preamble. 



The red part is the hot patching instruction, it's usually "mov eax,eax" which has no effect but to 
reserve space for hot patch installation. It's 2 bytes instruction which can make the hot patching process 
race-condition free. 

Sometimes original binary doesn't have it and patched binary has it. That makes the basic block looks 
modified. So DarunGrim2 ignores any hot patching instructions. When a instruction that is doing 
"mov" operation on same register at the start of a function, DarunGrim2 ignore them when generating 
basic block fingerprint. 

Basic Blocks in Multiple Functions 

Usually one basic block belongs to one function. But for optimization reason, there are some cases that 
one basic block can be part of multiple functions. 

Here's a basic block at 41fbc2 from Windows kernel disassembly. The IDA disassembler reports it part 
of "MmCopyToCachedPage" function. 




But from code flow analysis using custom tool, we found that the specific basic block belongs to more 
than one function. 



From the above analysis result, you can see that basic block at 41fbc2(in yellow color) is parts of 
function "MmUnmapViewInSystemCache", "MmCopyToCachedPage" and "MiRemoveMappedPtes". 
This kind of multiple function ownership of a basic block can prevent proper binary diffing process. 
The limitation with IDA is that it only supports one function match for one basic block. DarunGrim2 
solves this problem by doing custom CFG analysis and make it possible for a basic block belong 
multiple functions. 



Instruction Reordering 

In real world, instruction reordering is not happening a lot. Especially with Microsoft's binaries, we 
didn't see that much of instruction reordering cases. But during ARM binaries diffing experiments, we 
found that there are a lot of instruction reordering happen over each releases. "Illustration 4: Instruction 
Reordering in ARM Binaries" is a diffing result from iPhone 2.2. vs 3.0 binary. The function in 
question is matched by name matching, but the root node is colored yellow, which means the basic 
block is different. 
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Illustration 4: Instruction Reordering in ARM Binaries 



So we checked the disassembly of two basic blocks. 



Table 1: The original disassembly (same colors for same instructions) 

The original and the patched basic block is basically same. The only difference is the order of each 
instructions many of the instructions are swapped. 

So to solve this instruction reordering problem, we use grouping using variable tracing and sorting 
method. We can follow each register or displacement variable's change and usage paths. For example 
"Illustration 5: Part of register,displacement variable and call arguments trace of the patched basic 
block" shows some part of patched binaries basic block's variable traces. DarunGrim2 currently support 
register, displacement variable and call arguments tracing. 

By using variable tracing we can group each instruction nodes. There can be multiple groups and they 
are independent each other and the order of instruction between them will not affect each other. We 
calculate hash value from each groups. The hash will use instruction type and operand's type and value. 
We intentionally ignores any immediate value or memory references. They tend to be random across 
each builds and will prevent proper calculation. With the hash value calculated, we sort each block and 
list them in sorted order. 
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Illustration 5: Part of register,displacement variable and call arguments trace of the 
patched basic block 

"Table 2: After Grouping And Sorting" shows the result of grouping and sorting. They show same 
sequence of instructions except immediate and memory reference values. This instruction re-reordering 
process consume more CPU than original way of gathering sequential fingerprint. So this feature can 
be optionally used when necessary. 




Table 2: After Grouping And Sorting 



Examples 

We will show the result of binary diffing of real Microsoft patches to show the effectiveness of 
identifying patched points. We will use 3-4 critical-rated patches as examples. The critical and hard-to- 
find vulnerabilities doesn't need to be hard to pinpoint in the patches. We will use DarunGrim2 to 
demonstrate this. 



Microsoft's Binaries 

Why are Microsoft's binaries easy targets? 

They ship security patches in every second Tuesday of the Month. So the patches tend to contain only 
security fixing codes. Usually there is no feature enhancements or other types of patches are included 
in the patch. The feature enhancements are in service pack, not in monthly patch. So you can get pure 
security related patched parts with binary diffing. 

They also provide symbols. They usually provide symbols for system dlls and drivers and kernel 
images. They don't provide symbol for non core OS products like IIS or Active Directory or Microsoft 
Office. But many critical vulnerabilities are found in system DLLs, drivers and kernel, the attacker can 
use the symbols Microsoft provides to get more confidence in binary diffing. And it also saves a lot of 
time understanding the codes that modified. 

They don't do any code obfuscation. Aside from code optimization, they usually never do code 
obfuscation. Actually if they do code obfuscation, it will make a lot of problems. For example, it can 
conflict other products and also make debugging process very hard for them. So I think they will never 
be able to use code obfuscation technique for their shipping products. 

This makes the process of binary diffing more easy and cost effective. Amount of modified codes in 
patch is relatively small compared to other vendors. This means Microsoft is doing well in their code 
maintenance. In the point of binary differs' view, it's a low hanging fruit. 

Gathering Binaries 

It's very easy to gather Microsoft's binaries. You can just visit each patches page. For example for 
MS08-067 issue, you can visit http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx 
and you can download binaries that matching your operating system. Then you can extract the binaries 
inside the package using "/x" option. You can find older version of the binaries from your harddisk and 
open IDA and load the files and just start the diffing. This whole process usually takes little than 30 
minutes. 

The infamous MS08-067(which was exploited by Conficker) 

MS08-067 is a very interesting patch. It's patching stack buffer overflow problem inside netapi32.dll. 
And the real problem is that the stack overflow can be reached through anonymous pipe, which means 
this exploit can be exploited remotely without any credentials. This vulnerability was used with 
Conficker worm to propagate through internal network after it infects any machine in the network. 

From the point of binary diffing, MS08-067 is a very easy target. Identifying the modified block just 
takes few minutes. And there is only 2 functions changed. And one is a change in calling convention. 
So there is only one function changed. 




Illustration 6: Differences between two matching functions are 
massive 



Of course, you need more research and analysis of the patched function to get what was really causing 
the vulnerabilities happening. It's not in the range of binary diffing art itself. Binary diffing is a starting 
point of whole patch analysis. Especially for MS08-067 patch, the modified codes are enormous, we 
can easily guess that it might be a huge mistake in processing some data. More analysis will reveal the 
actual vulnerabilities. 



MS08-063: DarunGrim2 vs bindiff 

Binary diffing with DarunGrim2 will show following functions are modified. You can check them one 
by one to find any interesting basic block additions. The "Illustration 11: Screenshot from bindiff 
manual" shows the list of modified functions. 



Original | Unmat.,, | Patched Unmat,,. 


Different 


Matched 


M... ' 


□ _SrvCo-mpleteRf cbClose@4 


_SrvCompleteRfcbClo$e©4 1 


3 


IS 


90% 


□ ©SrvRertartRawReceive©4 


©SrvRestartRawReceive@4 1 


5 


25 


90% 


□ .Srvlssu eQu eryD i recto ryReq u est@32 


_SrvI::ueQuei' Direct cr : Request@32 2 


1 


23 


94% 


□ funclD0E4 


func 1CD48 


1 


11 


95% 


□ ©SivPsdRestartPrepareRawMdlWrFte... 


©SrvFsdRestartPrepareRawMdlWrite©4 3 


1 


43 


95% 


D _SrvRequestOplock©12 


_SrvRequestOplock@12 


2 


40 


97% 


□ _G en erateOpen2Res : c n se@8 


_GenerateOpen2Response©8 


1 


57 


99% 



Illustration 7: Modified Functions 



The "_SrvIssueQueryDirectoryRequest@32" has the patch that is supposed to fix the security issue. 
The zoomed-out call graph of the function looks like following. 




Illustration 8: Zoomed out view of the modified 
function(_SrvIssueQueryDirectoryRequest@32) 



The original basic block that is modified is like following. 



Illustration 9: 
Original basic block 
that is modified 




Illustration 10: The patched parts 



In "Illustration 8: Zoomed out view of the modified function(_SrvIssueQueryDirectoryRequest@32) M 
The red blocks below are the additional basic blocks and they are doing sanity checks for the data. 

From the patch you can see it's calling "RtlUlongSub" function and returns COOOOOODh return code 
according to the result. With further tracing of what data it's checking sanity, you can see what kind of 
vulnerabilities it's fixing. 

So DarunGrim2 finds 7 modified functions. And if you look into each changes most of them have some 
kind of sanity checks or something meaningful changes added. 

If you look into bindiff s manual page, you can see binary diffing example using this exact same 
binaries. But, the screenshot from the bindiff help file shows only 3 function changes. 



So as Halvar mentioned in his paper, function fingerprinting using nodes, edges and call count usually 
have few false negatives. And sometimes they are critical if the patch is done without changing the 
CFG structure. 

Here's the graph screenshot from bindiff help file showing "_SrvIssueQueryDirectoryRequest@32" . 
Primary is patched file and secondary is original file. And you can see that the diffing result is same as 
DarunGrim2. 





Illustration 11: Screens hot from bindiff manual 



Tff= 



So this diffing example shows that DarunGrim2 diffing scheme is useful and practical as much as 
bindiff. And sometimes if you want more detailed depth of diff analysis DarunGrim2 might show better 
results. But this doesn't mean that which tool or algorithm is superior or inferior. Both of them has their 
own strength and weakness, so you need to choose the tool and algorithms according to your specific 
diffing needs. 



MS09-020: WebDav case 

By diffmg the patches, the following functions are shown as matching and modified. The interesting 
thing on this issue is that there is no unidentified blocks in original or patched binaries. Only 9 basic 
blocks are modified. 



?ScConvertToWide@@YIJPBD... ?ScConvertToWide@@YlJPBDPA... 

Illustration 12: The Function Match Line 



lu 



16 S0 C 3 



So the most significant change happened in following basic blocks. The following is showing the 
blocks from original binary. 



■ yyZ - nvert T: '. Vide ,§ ;§Y J =' B D P Al PAGOH @Z 

1 3a «H, [HIM] 



iK. [ebp-12Ch] 

push dword plr [eas] , cchWideChar 

mm eax. [ebp-124h] 

push dword prr [ebp-130h]; Ip'w'ideUharStr 



pushean; dwFlags 

push dword plr [ebp-124h]; CodePage 

call edi ; MultiBjjteTo'widfC hirl I M.jinBijteToWideChar( 



jn£ short loc_6F069752 



call ds: imp QetLastError@>0; Ge(LastError() 

cmp eaK, 7Ah 
jnz short loc_6F069724 



Illustration 13: Original binary 
And the following is the basic blocks from patched binary. 



push dword ptr [etui] : cchWideChar 

Js:_imp_MultiBsteToWideChar@24;MuHiBgteToWideChar(K,K 

push dword per [ebp-12Ch]; Ip'w'ideCharStr 

lea edi, [ean*1] 

push edi ; cchMuluByi.e 

push dword ptr [ebp-124h], IpMultiByteStr 

push 8 ; dwFlags 

push dword per [ebp-128h]; CodePage 

:i ; MultiByte Tc.V.''idfChar(::,::,K,!:,x,:<|, MultiBgteToWide Char|>,::,::,x, 



jr.: sr 



c_8F063/39 



ebs, ds: imp GetLastError@0; GetLastE 

call *b:: ; GetLastErrorO, GetLastErrorO 
emp eaK, 7Ah 



Illustration 14: Patched Binary 

The difference is unnoticeable at first. But you can find that the 2 nd argument for 
"MultiByteToWideChar" call is changed. The original binary is getting it using following assembly 
sequences. 




It's doing some arithmetics using "eax" and the result is used for the flag of the call.But if at address 
6F069641, the call for "FisUTF8Url" function returns TRUE, "esi" and "[ebp-124h]" will have same 
value. So the flag will be 0. 



MSDN( http://msdn.microsoft.com/en-us/library/dd319072fVS.85).aspx ) declares like following: 



The "FIsUTF8Url" is not complete UTF8 recognizing routine, but it's doing some heuristic character 
range checks to see if the string looks like UTF8. Even though the string looks like UTF8, it still can be 
invalid UTF8 string. And you don't specify the "MBERRINVALIDCHARS" flag, the function will 
convert the string ignoring the errors. 

This vulnerability is special, because the fix doesn't incur any CFG structure change. The only change 
is some instructions inside blocks. CFG based matching tools like "bindiff ' have possibilities to miss 
these kinds of patches. 



Non-MS Binaries 



JRE Font Manager Buffer OverflowfSun Alert 254571) 

It's also possible binary diff binaries without symbols. Sun Microsystems doesn't provide symbols for 
their binaries. But with binary diffing of the target binaries, you can get the following result. 



3 i„,l, Fi„g„p,i l „ l p S lch«li Pa,e„,.0rigin3l, P„ 



Illustration 15: Overview of the Difference 
The unpatched binary looks like following. 



6D2C4A74 

push edi 

mov edi, [esp.10h] 

lea eaK. [edUOAh] 

cmp eax. 2000000h 

jnb short loc_6D2C4A8D 



X 



Illustration 16: The Original Parts 
The patched binary has following. 



\ 



jnb short loc_6D244B25 




Illustration 17: The patched parts 

From IDA, I retrieved more parts of disassembly. The original and patched parts looks like following. 
The patched binary has additional lines in red. 



If you look into the red part, you can see that the part is checking edi register's value is over 2000000h. 

Orignal check only ecx(which is edi+Oah) value is over 2000000h( 6D2C4A7C). The additional edi 
value check actually prevents integer overflow. For example edi is Oxffffffff, then ecx will be 



0xffffffff+0xa=0x9. In Orignal binary ecx will pass the test because it's smaller than 2000000h. But in 
the patched binary the cmp edi,eax in address 6D244B10 will filter big edi value. This can help prevent 
integer overflow. 

So we can know that there's a integer overflow is happening in this part. And with further investigation 
we can find where the data is coming in. It must be somewhere the attacker can control. 

Actually the original advisory heref iDefense Security Advisory 03.26.09: Sun Java Runtine 
Environment (JRE) Typel Font Parsing Integer Signedness Vulnerability ) describe the vulnerability as 
following 



So we see the patch we just found just matches the vulnerability description. 

Anti-Binary Diffing 

So now it became crucial to make these practices more difficult and time-consuming so that earn more 
time for the consumers to apply patches. Even though using severe code obfuscation is not an option 
for Microsoft's products, they can still follow some strategies and techniques to defeat the binary 
diffing processes without forsaking stability and usability. We are going to show the methods and 
tactics to make binary differs life harder. 

We will give some ideas and informations on how to prevent effective binary diffing. We are going to 
show tactics and algorithms that can be used to defeat the binary diffing methods. Some are related to 
practices and processes that the vendors are doing and others are totally technical. 

We can think of some measures to prevent this kind of binary difference analysis. 



Symbol Mangling 

We can think about changing symbol names for the procedures. Many implementations are basically 
dependent on symbolic name of procedures and variables. So if we use different names for original and 
patched binaries then we can make name based procedure matching useless. BMAT is actually heavily 
dependent on name matching, and they are also doing similarities based name matching. So we need to 
mangle the names to avoid the heuristic name matching. 



Reordering and replacing instructions 

Some binary diffing tools are using code checksum for matching basic blocks. And the checksum is 
order dependent sometimes. In that case just reordering or replacing existing instructions to alternates 
will make the matching fail. 

CFG Altering 

Some tools like bindiff is dependent on CFG signatures of each functions. How about if ruin this 
signature by adding fake nodes and edges and calls. So the function signature will be modified and the 
fixed points identifying process will fail. By putting a branch that will never be taken, you can break 
CFG and make diffing algorithms based on CFG break. 



By altering the structure of procedure's CFG or program's CG without changing functionality, it's 
possible to make binary difference analysis tools based on structural analysis fail. This method also 
affects isomorphic analysis based binary matching. Because the graph structure must be matched for 
each binaries, just putting few meaningless blocks or instructions will confuse function signaturing 
process. Something to note is that we need to put the CFG mangling blocks to enough number of 
functions. If it's concentrated around the patched function, it only makes the patched point more 
visible. 



Use proxy call 

Prevent CG Recognition 

Replace call <XXX> to call <YYY> and the function YYY will look like following 



Function YYY is basically null function without any functionality other than call proxying. In case 
disassembler of binary differ recognizes this null functions, you can put some non-functioning garbage 
instruction to deceive disassembler or binary differ. 

Call that never returns 

Actually this idea came with some real world case where DarunGrim2 was deluded where 
RpcRaiseException broke CFG and prevented matching of functions. This will break CFG seriously. If 
you put a call that is never returning and put a function block just next to that "call XXX" instruction. 

Change instructions like following: 



To something like following. 




The call will never return and if the code part that is next to "jz A" line will be recognized as belonging 
to their functions. If you place a basic block from other functions there, it will totally break the function 
's block ownership recognition. 

Sharing Basic Blocks 

Sharing basic blocks by multiple functions can break CFG and CG. Sometimes compiler perform 
optimization sharing same basic blocks between multiple functions. The basic blocks shared must be 
contain returning basic block. So it's not easy to find this kind of basic blocks that is same for any given 
functions pair. 

Use multiple heads for a function 

If you make multiple entry point to a function, you can effectively confuse disassembler from 
recognizing real function entry point. To make the fake function head(entry point) more realistic, you 
can make a fake basic blocks that is calling the fake head. This will convince the disassembler to 
believe that the fake head is also valid one. So this will prevent proper function-block matching and 



will affect binary diffing using graph isomorphism. 

Anti Binary Diffing Tool: Hondon 

We will implemented in-house tool called "Hondon"(in Korean means chaos) to show that it's possible 
to defeat major commercial and freeware binary diffing tools. It can be used to obfuscated binaries so 
that the patched points are buried under other meaningless differences. The obfuscated code parts 
should not affect the performance of the module nor it should not make the debugging difficult. As to 
say, it should not have any serious side effects other than preventing binary diffing. It will just make the 
patched code parts invisible and buried among obfuscated fake patched parts. 
Hondon is implementing most of the methods presented here. And you can run it as a IDAplugin. It 
will be dependent on IDAs disassembling ability. That's better than a tool has full blown disassembler 
because you can manually correct what IDA's disassembler mis interpreted. If we provided our own in- 
house disassembler, it would make the feedback process almost impossible. So you run this as IDA's 
plugin, it will rewrite the target binary as binary-diffing-proof binary. 

Conclusion 

So we looked into the history and current state of binary diffing art. The 1-day exploit threat is real and 
currently happening every patch days. Sometimes some people diff different version of product, for 
example, IE6 and IE7 binaries and find some vulnerabilities fixed silently. And the points where 
vulnerabilities are fixed are good starting points for further vulnerabilities hunting. Bugs tend to 
aggregate and many times around where bugs were found, another bugs reside. Or some fixes are 
incomplete and someone can find those facts and can exploit the conditions. 

So as the attacking technology improves, the protection techniques need to evolve accordingly. Some 
major vendors are reluctant to use severe form of anti debugging, because it can break things. So they 
need some lightweight, non-aggressive and effective way for defeat binary differs. We presented 
"Hondon" which exploit binary-differs weak points. As anti-binary diffing technology evolves, binary 
differ will evolve, too. They will process the broken CFGs and also do strong form of instruction 
reordering or use other techniques. So the story will continue... 
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